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The ICARE method is a flexible, widely applicable method for systems engineers to solve 
problems and resolve issues in a complete and comprehensive manner. The method can be 
tailored by diverse users for direct application to their function (e.g. system integrators, 
design engineers, technical discipline leads, analysts, etc.). The clever acronym, ICARE, 
instills the attitude of accountability, safety, technical rigor and engagement in the problem 
resolution: Identify, Communicate, Assess, Report, Execute (ICARE). This method was 
developed through observation of Space Shuttle Propulsion Systems Engineering and 
Integration (PSE&I) office personnel approach in an attempt to succinctly describe the 
actions of an effective systems engineer. Additionally it evolved from an effort to make a 
broadly-defined checklist for a PSE&I worker to perform their responsibilities in an 
iterative and recursive manner. The National Aeronautics and Space Administration 
(NASA) Systems Engineering Handbook states, “engineering of NASA systems requires a 
systematic and disciplined set of processes that are applied recursively and iteratively for the 
design, development, operation, maintenance, and closeout of systems throughout the life 
cycle of the programs and projects.” ICARE is a method that can be applied within the 
boundaries and requirements of NASA’s systems engineering set of processes to provide an 
elevated sense of duty and responsibility to crew and vehicle safety. The importance of a 
disciplined set of processes and a safety-conscious mindset increases with the complexity of 
the system. Moreover, the larger the system and the larger the workforce, the more 
important it is to encourage the usage of the ICARE method as widely as possible. According 
to the NASA Systems Engineering Handbook, “elements of a system can include people, 
hardware, software, facilities, policies and documents; all things required to produce system- 
level results, qualities, properties, characteristics, functions, behavior and performance.” 
The ICARE method can be used to improve all elements of a system and, consequently, the 
system-level functional, physical and operational performance. Even though ICARE was 
specifically designed for a systems engineer, any person whose job is to examine another 
person, product, or process can use the ICARE method to improve effectiveness, 
implementation, usefulness, value, capability, efficiency, integration, design, and/or 
marketability. This paper provides the details of the ICARE method, emphasizing the 
method’s application to systems engineering. In addition, a sample of other, non-systems 
engineering applications are briefly discussed to demonstrate how ICARE can be tailored to 
a variety of diverse jobs (from project management to parenting). 


I. Introduction 

T HE ICARE Method is partially inspired by the long-time drivers education teacher at Monroe High School, Mr. 

Larson. His students affectionately referred to him as Mr. IPDE, because they heard his instructions over and 
over to Identify-Predict-Decide-and-Execute. This is an effective method for new drivers to watch the road, identify 
any potential collisions, predict what is going to happen, decide how to best avoid the situation, and execute by 
maneuvering the car appropriately. The IPDE method is intended just for the driver, so it falls short in a more 
complex environment with more players, levels of management and customers. The ICARE method meets the 
expanded scope by including Communication between the many parties involved, Assessment of all the applicable 
products and processes, and a Report of the assessment results to the decision authority. 

The intent of the ICARE acronym is to instill in the systems engineer the attitude of engagement and proactive 
examining of the system. With a heightened awareness and critical thinking mindset, the systems engineer will more 
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effectively perform the role of identifying and solving complex problems. The nature of integrated system level 
problems makes them particularly difficult to identify because they involve interactions between multiple 
subsystems, which are typically designed independently. Further, solutions to system level problems most often 
require an iterative compromise between the subsystems. 

The NASA Procedure Requirement for Systems Engineering Processes and Requirements, NPR 7123. 1A, 
defines “iterative” as the “application of a process to the same product or set of products to correct a discovered 
discrepancy or other variation from requirements,” and “recursive” as “the repeated application of processes to 
design next lower layer system products or to realize next upper layer end products within the system structure. This 
also applies to repeating application of the same processes to the system structure in the next life-cycle phase to 
mature the system definition and satisfy phase success criteria.” As it pertains to the Space Shuttle Program (SSP) 
currently in the operational phase, the ICARE method is iterative in its application to resolve system level or 
integration issues in the system, elements or subsystems. The ICARE method is recursive in its repeated application 
to resolve system level or integration issues through the processing cycle of each mission. 

All of the NASA Directives referenced in this document can be found in the NASA Online Directives 
Information System (NODIS) Library. 1 


II. Identify 

The first step in solving a problem, resolving an issue or capitalizing on an opportunity is to identify the 
problem, issue or need. It is extremely important to accurately and precisely identify the issue, so the problem- 
solving process gets started in the right direction and, ultimately, the resolution fully addresses the issue. Inaccurate 
identification can mislead the problem solver and divert the effort, costing time and money, and increase the 
likelihood of not solving the right problem. 

There is a temporal aspect to the Identify step in that issues can be identified before, during or after their 
occurrence. An important part of the systems engineering role is to make sure specific, adequate processes are in 
place to accomplish the identification of issues for each of these phases. The cost of correcting an issue depends 
heavily on when the issue is identified; typically, the later an issue is identified, the more costly it is to fix. Once an 
issue is identified, the ICARE steps have begun, and the rest of the steps must be completed to fully address the 
issue. The following are examples of methods or processes used by NASA, which align with the ICARE method, 
that address issues before, during and after they occur. 

Failure Mode and Effects Analysis (FMEA) and Critical Items List (C1L), Fault Tree Analysis, Hazard Analysis, 
Risk Management, and Technical Probabilistic Risk Assessment (PRA) are examples of processes used by NASA to 
identify and mitigate issues before they occur. Examples of processes used to identify issues while they are 
occurring include operational maintenance instructions, inspection criteria, launch commit criteria, interim problem 
reports, and flight rules. Problem reports and non-conformances, Root Cause Analysis and Mishap Investigation are 
examples of methods used after an issue has occurred to identify the cause of the issue. Describing these processes 
in detail is outside the scope of this paper; however, references will be provided for the reader’s benefit. It suffices 
to say that the importance of issue identification is highly emphasized by NASA, which is evidenced by the 
multitude of requirements, processes and tools, as well as the safety culture ingrained in NASA employees. The “I” 
in ICARE makes it personal for the systems engineer to take responsibility and do their best to identify issues or 
problems. 

The best time to fix a problem is before it happens. FMEA; Failure Modes, Effects, and Criticality Analysis 
(FMECA); and fault trees are methodologies designed to identify potential failure modes of a product or process, to 
assess the risk associated with those failure modes, to rank the issues in terms of importance, and to identify and 
carry out corrective actions to address the most serious concerns. According to MIL-STD-1629, FMECA is an 
ongoing procedure by which each potential failure in a system is analyzed to determine the results or effects thereof 
on the system and to classify each potential failure mode according to its consequence severity. A fault tree 
evaluates the combinations of failures that can lead to the top event of interest 2 . Per NPR 7123. 1A, FMEA is 
referred to as a Safety and Mission Assurance product for the Preliminary and Critical Design Reviews; also, FMEA 
is noted as an activity to take place during the Logical Decomposition and Design Solution Definition Processes. 3 
Requirements and guidelines for conducting FMEA are particular to each NASA program or project and are flowed 
down in the program requirements. The space shuttle document that accomplishes this is NSTS 22206, 
“Requirements for Preparation and Approval of Failure Modes and Effects Analysis (FMEA) and Critical Items List 
(CIL).” 

Another safety and reliability analysis technique used in the design solution definition is Preliminary Hazard 
Analysis (PHA). “PHA is a ‘what if process that considers the potential hazard, initiating event scenarios, effects. 
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and potential corrective measures and controls. The objective is to determine if the hazard can be eliminated, and if 
not, how it can be controlled. 2 Similarly, but later in the project life cycle, hazard analysis evaluates the completed 
design. In the SSP there are hazard reports regarding the individual elements as well as the integrated system. 

According to NPR 7123. 1A, “the technical risk management process is used to examine on a continuing basis 
the risks of technical deviations from the project plan and identify potential technical problems before they occur so 
that risk-handling activities can be planned and invoked as needed across the life of the product or project to 
mitigate impacts on achieving product-line life-cycle phase exit criteria and meeting technical objectives. 3 ” The 
NASA procedural requirement for defining this process is NPR 8000.4, The Risk Management Procedural 
Requirements. PRA provides one means of identifying and assessing technical risk. The NASA Procedural 
Requirement NPR 8705. 5A provides the basic requirements for performing a technical PRA for NASA programs 
and projects. 4 ' 5 

Processes that are used to identify issues when they are occurring will depend on the system, life cycle phase and 
its operation. In general, the systems engineer should ensure the appropriate processes are in place to promptly 
identify real-time issues and provide predetermined corrective actions. In the SSP, day-of-launch operations 
exemplify this point. The procedures for loading the vehicle with cryogenic fuels and the crew, among many other 
activities, are written in operational maintenance instructions. Specific procedures that are particularly hazardous are 
indicated, and the critical steps for safing the vehicle and crew are documented. The Final Inspection Team observes 
the vehicle in a fully-loaded configuration and confirms, using documented inspection criteria, that the outside of the 
vehicle appears to be ready for launch. In addition to visual inspection, the vehicle and ground support equipment is 
instrumented to provide engineers insight into the vehicle health. The real-time data is compared to documented 
launch commit criteria that ensure the vehicle is ready to launch. Engineers constantly examine the data, monitoring 
for trends or indications of a problem. If any potential problems are identified, they are recorded as interim problem 
reports that must be resolved prior to a particular loading milestone depending on the issue. After the space shuttle is 
launched, when it clears the launch tower, responsibility for monitoring the vehicle is taken over by mission control 
in Houston. The flight controllers monitor real-time data, and if potential problems are identified, flight rules are 
used to correct the situation and/or ensure the safety of the crew. 

In addition to the procedures and processes used during operations. United Space Alliance, LLC., NASA’s prime 
contractor that operates and processes the space shuttle vehicles, empowers their employees with a Time Out Card, 
because “every employee has the obligation to call a time out” if something is not safe. The Time Out Card is a 
laminated card that can be clipped to an employee’s badge. The concept of the Time Out Card may be used with or 
without the physical card, and the intent is to allow every employee the ability to “press the pause button” on an 
operation that is deemed to be unsafe. 

After an issue occurs, if the systems engineer only identifies symptoms of the problem and does not discover the 
root cause, it is very likely that the solution will not adequately address the problem, and the problem will recur. 
Root cause analysis and failure analysis methods are widely used by NASA. The NASA Process Control Focus 
Group training presentation states, “Root Cause Analysis is a method that is used to address a problem or non- 
conformance, in order to get to the ‘root cause’ of the problem. It is used so we can correct or eliminate the cause, 
and prevent the problem from recurring. 6 ” NASA designed the Root Cause Analysis Tool Software “to facilitate the 
analysis of anomalies, close calls, and accidents and the identification of appropriate corrective actions to prevent 
recurrence” specific to NASA applications. 7 Further, there is a website maintained by the NASA Headquarters 
Office of Safety and Mission Assurance “to provide a collaborative environment between government agencies, 
academia, and the commercial sector to promote the exchange of knowledge and advance the development of 
accident investigation methodology and tools. 8 ” 

To this point the discussion has been focused on identifying issues or problems. The ICARE method can also be 
implemented to identify an opportunity or a need, as opposed to a problem or risk that must be addressed. For 
example, a systems engineer could identify manufacturing enhancements that reduce the amount of production time, 
materials used, or production risk. A systems engineer or program manager could identify a mission or test objective 
of opportunity. However, the Risk Management Procedural Requirements (NPR 8000.4) do not address positive 
risks or opportunity, and there seems to be no such NASA process or requirement that defines opportunity 
management and how it should or could apply to NASA. In the SSP, the process for identifying opportunities, 
improvements and advancements is not managed formally in a periodic manner. Moreover, there are contract 
clauses for the shuttle contractors to perform continuous improvement activities, but these activities are typically not 
managed formally. Rather, continuous improvement activities are implemented by incentivized programs. 

In summary, for the systems engineer, the purpose of the Identify step is to perform proactive monitoring of the 
subsystems and discover issues that could be of interest to the systems integration community. The “could be” in 
that statement implies further work, during the Communicate and Assess steps, that must be done to determine if the 
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issue is truly an integration or system level concern and to what extent. There are many processes and methods 
required by NASA to ensure issues are identified before, during and/or after their occurrence. Definitions and 
references of those processes have been provided for the reader’s benefit. 

TIT. Communicate 

The second step in resolving an issue is to communicate the issue to all stakeholders, customers, managers, 
system owners, design engineers and technical discipline engineers or subject matter experts. Obviously, there is an 
appropriate time, order, forum and medium for communication with these groups. In the ICARE method the 
distinction between Communicate and Report is a matter of timing and formality. The communicate step is intended 
as an initial step in making the potential issue known; whereas, the Report step is intended to be a more formal 
communication of the entire issue, all of the impacts, assessment results, and recommendation to the decision 
authority. However, even for the informal communication conducted during the Communicate step, a process may 
be provided or dictated by the organizational structure, work instructions or contract agreement; if not, the systems 
engineer must determine the best approach in which to communicate the issue. 

Communication is an extremely important aspect of systems engineering and integration. Integration is not only 
putting the hardware pieces together, but it is the sharing of data and information with the broader community, 
organizations and technical disciplines. The Propulsion Systems Engineering and Integration Office (PSE&IO) is 
organized into two main groups. Element Integration and Systems Analysis. The Element Integrators are assigned to 
a specific element of the space shuttle system; External Tank, Solid Rocket Booster, Space Shuttle Main Engine and 
Reusable Solid Rocket Motor. The role of the Element Integrator is to actively participate in the Element meetings, 
reviews, discussions, etc. and identify issues or concerns that may have system implications and thus be of interest 
to the systems engineering and integration community. The Element Integrator assesses problem reports, non- 
conformances, in-flight anomalies, schedules, technical panel and control board topics, requirement changes, launch 
commit criteria changes, interface control document changes, and technical issues that arise during shuttle 
processing. 

When a potential issue is identified by an Element Integrator, it should be communicated to the element 
engineers that there is potentially a concern from the integration perspective. This is typically an informal 
communication that proves important as issues are worked. Letting the element engineers know up front that the 
integration community might have concerns eliminates (or reduces) the surprise later in the problem-resolution 
timeline. If there is a lack of communication up front, there is potential that an issue may need to be reworked; or, 
unintended consequences elsewhere in the system might result. After the Element Integrator identifies a potentially 
integrated issue and gives the element personnel that insight, the next step is to communicate the concern to the 
systems engineering and integration community, as well as other element projects that might be impacted. The 
purpose is simply to inform the community so all systems and effected elements are aware of the potential issue. 

Often, there is some uncertainty whether or not an issue is truly an integration concern. This fact makes it 
difficult for the Element Integrators to determine the appropriate time to communicate the issue to the integration 
community. When in doubt, the conservative approach is to communicate the issue to at least a subset of the 
community to get their perspective. Managers and chief engineers will offer guidance on the potential integration 
impacts. 

The System Analysis engineers are PSE&I representatives in the technical discipline panels chaired by 
engineering and the technical forums chaired by the element project office personnel. Like Element Integrators, 
System Analysis Engineers have the responsibility to monitor the system, identify issues and communicate those 
concerns to the element personnel and integration community. The System Analysis engineer’s perspective will 
naturally be from their technical area of expertise (e.g. aerodynamics, structural loads, stress, thermal, etc.). In the 
SSP the technical panels are, by definition, an integration function, so issues identified by them are almost always an 
integration concern. 

Choosing the best time to communicate a potential issue can be a tricky task. Care must be taken to balance the 
time it takes to develop the story regarding an issue and the need for community awareness of the issue. When an 
issue can cause immediate harm, communication must happen rapidly and directly. Sometimes it is not so obvious, 
when a potential issue is discussed informally at “low levels’’ in the program, and the criticality of the potential issue 
is unknown. In this case, the sensitivity is that the potential issue may be raised to a high level prematurely and turn 
out to be a non-issue. The consequence is creating work when there is no need and possibly even putting strain on 
the working relationship between the systems engineer and subsystem co-workers. Conversely, the potential issue 
might be communicated too late and result in an accident that was preventable. Either scenario, communicating an 
issue too early or too late, is not healthy in the work environment and may yield negative outcomes. 
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The order in which co-workers, managers, customers and other stakeholders are informed of potential issues is 
important. Policy, protocol or guidelines should be established for situations and scenarios that commonly occur. A 
chain of command or levels of communication can be established to clarify the responsibility and expectations of 
how employees communicate issues. Regularly held meetings or communication forums should be structured to 
provide visibility of issues to increasingly higher levels of leadership. The frequency of the meetings should depend 
on the pace and criticality of the work environment. The meeting structure should provide a progression of 
audiences that refine the topic and address all possible perspectives prior to reaching the next level of leadership. 

In PSE&I, routine weekly meetings are scheduled to communicate issues. The Element Integrators and System 
Analysis engineers have weekly meetings and teleconferences with their respective element or discipline engineers 
to discuss topics of interest. Each group examines issues and identifies which potential issues should be 
communicated to the integration community. At the end of the week, all these potential issues are discussed with the 
team leads and other Element Integrators, and the team leads determine which issues should be communicated to the 
managers. 

The Element Integrators and System Analysis engineers are not necessarily responsible for performing all steps 
of the ICARE method. The Element Integrators and System Analysis engineers must identify and communicate, but 
the responsibility shifts when the issue is confirmed to be integrated and a lead for the issue is assigned. The systems 
engineer designated as the lead of the issue, which may be an Element Integrator or System Analysis engineer, is 
responsible to complete the ICARE method and resolve the issue. Full resolution of an issue typically requires 
iteration of the ICARE steps; therefore, it is important that the Element Integrators and System Analysis engineers 
remain engaged in the remainder of the steps (Assess, Report and Execute). Further, the Element Integrators or 
System Analysis engineers need to communicate statuses or unintended consequences that may arise during the 
problem resolution back to the Element engineers. 

IV. Assess 

The third step in resolving an issue is to assess impacts to all products, people, processes, activities and tools. 
The systems engineer must determine all impacts of the issue and all interactions with other subsystems. This step 
confirms whether the identified issue is indeed an integration concern and determines to what extent. In addition to 
assessing the impacts to the integrated vehicle, the systems engineer should identify any impacts to the subsystems 
or other elements and communicate those to the subsystem or element representative for assessment. 

The Assess step is the defining step for an effective systems engineer. In complex systems even the smallest of 
defects can result in catastrophe. System interactions are extremely difficult to assess in full detail, because the 
parametric space is usually unmanageable and analytical tools do not include all the variables. Sensitivity studies 
can be conducted to understand some of the driving parameters, but the uncertainty in the analysis is never fully 
characterized. Non-linearity that often exists in system level analyses further complicates the assessment task. The 
systems engineer is instrumental in driving out the system interactions and understanding the criticality of every 
issue observed. Knowing what analyses to conduct and when to ask more questions to probe deeper into an issue is a 
skill that a systems engineer must possess to be effective. The steps in the ICARE method can help guide a systems 
engineer through the problem-resolution process, but the value of the method is in the augmented sense of 
accountability and responsibility when the systems engineer says, “I CARE.” 

The type of assessment required depends heavily on the issue being worked and the phase in the 
program/product life -cycle. The assessment might be informal in the initial stages; or, the stakeholders, customers or 
management might levy an action or directive requesting a particular assessment product with a prescribed due date. 
There may be guidelines in place or contractual agreements that define the amount of assessment that can be done 
prior to receiving direction from stakeholders, customers or management. If direction is not provided, the systems 
engineer must determine the appropriate amount of assessment before reporting the issue and results to the 
stakeholders, customers and/or managers. The severity and criticality of the issue, should dictate the amount of 
assessment. The time available to conduct an assessment can influence the type of analyses that are initially 
conducted; however, when safety is in question, the time to address the issue must be adequate to complete the 
assessment and ensure the vehicle and crew safety. This point cannot be stressed enough. The systems engineer must 
represent safety above all else and make sure the decision authority is properly informed to make sound decisions. 

An assessment might involve using models and simulations, analysis, testing, probability risk analysis, or 
establishing and monitoring measures of effectiveness or technical performance. Quantitative assessment might be 
required or qualitative results might be sufficient. Assessments may be predictive or reconstructive depending on 
when the issue is identified. Already existing analyses might be applicable to the issue, such as a FMEA or hazard 
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analysis, or the issue may prompt the need for a new assessment approach, such as a specialized Computational 
Fluid Dynamics simulation. 

In the SSP independent assessments are conducted by numerous entities for each issue that gets elevated through 
the reporting channels. The contractors conduct their own review of products they deliver to NASA. Then the 
products are reviewed by the appropriate technical panels, element project office engineers, management and chief 
engineers, the system level engineers, management and chief engineers, and the program level management and 
chief engineers. In addition, independent technical authorities from Engineering, Safety and Mission Assurance and 
Health and Medical are members of the key review and control boards . 9 For major issues that are worked, the NASA 
Engineering and Safety Center also performs value-added independent testing, analysis, and assessments of NASA’s 
high-risk projects to ensure safety and mission success . 10 The multitude of assessments and checks and balances in 
the system are intended to ensure no issues result in loss of mission, vehicle or crew. 

When considering systems engineering responsibilities over the life -cycle of a project, technical assessment is a 
technical management process defined in the NASA Systems Engineering Handbook as “the crosscutting process 
used to help monitor technical progress of a program/project through Periodic Technical Reviews. It also provides 
status information to support assessing system design, product realization, and technical management decisions.” 
The technical assessment process activities include preparing the strategy for conducting technical assessments, 
assessing technical work productivity (measure progress against plans), assessing technical product quality (measure 
progress against requirements), conducting horizontal and vertical progress technical reviews and capturing work 
products from technical assessment activities . 2 

Before the assessment is complete, or throughout the project life-cycle, periodic status reporting may be 
necessary, whether formal or informal, to ensure the assessment is on track and will satisfy the intended purpose. 
The Assess step is iterative to fully understand an issue or to re-assess an issue after mitigation has been 
implemented. The Assess step is recursive in nature to track an issue through the system design and product 
realization throughout the life-cycle. At an appropriate juncture or when the assessment is complete, the results 
should be reported to the stakeholders, customer, or management. Quite often, the Assess step gets revisited after the 
Execute step to probe deeper into an issue and increase understanding by conducting additional or more refined 
assessment. 


V, Report 

The fourth step in resolving an issue is to report the issue and assessment results to stakeholders, customers 
and/or managers (i.e. the decision authority). Organizational structure and control boards typically dictate how 
issues are to be reported. Further, guidelines or procedures are usually in place for the systems engineer to follow 
regarding the reporting process. In critical situations that require prompt action from the systems engineer, such as a 
console operator on launch day, the reporting protocol is rigidly defined and followed. 

In the report to the decision authority, the issue should be fully described to the level of detail required for a 
decision to be made. The systems engineer needs to ensure that the right amount of information and the correct 
information is provided to the report audience. The report should include the assessment results, the review they 
received and recommendations on how to proceed. The SSP review and control board structure has several levels 
and charters of responsibility to cover every angle of programmatic and technical concern. The board structure 
provides a progression of audiences that refine the topic and address all possible perspectives prior to reaching the 
next level of leadership. In addition, the three independent technical authorities mentioned in the Assess step have 
their own governance chain for reporting issues. 

For example, here is a typical review cycle for an issue related to the space shuttle liquid propulsion system: the 
contractor conducts an assessment that is reviewed internal to the contractor management and technical authorities 
prior to delivery to NASA. Then, the assessment is reviewed by the Propulsion Systems Integration Group and the 
element project office technical teams that are interested in the topic. Then the assessment gets submitted for review 
to the integration community prior to being presented to the Systems Integration Control Board (SICB). PSE&I, and 
any other interested project offices or directorates, will review the assessment in their programmatic and chief 
engineer review boards as part of the integration community review. If the topic warrants higher visibility or 
approval, the assessment will be presented to the Program Requirements Control Board after the SICB. Depending 
on the issue being worked, there may be other technical groups that would have to review the topic as part of this 
cycle (e.g. the Launch Commit Criteria Working Group would be an integral reviewer/contributor to an issue that 
impacts launch commit criteria). 

NASA is highly committed to safety because their missions are inherently risky and extremely dangerous. 
NASA’s goal is to protect the astronauts and civilian population and keep the public’s trust and faith. In addition to 
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the normal reporting process in any program, NASA has multiple paths to elevate safety concerns. If an employee 
feels as though their dissenting opinion has not been adequately addressed, it is their right and responsibility to 
report the safety concern in another authorized forum to receive more attention. For example, the NASA Safety 
Reporting System (NSRS) is an anonymous, voluntary, and responsive reporting channel to notify NASA’s upper 
management of concerns about hazards. The report is guaranteed to receive prompt attention. Established by the 
NASA Administrator in 1987 after the Challenger Shuttle mishap, the NSRS has since supported all flights and has 
been expanded to cover all NASA operations. 1 1 

The systems engineer who is leading the problem resolution must ensure that all the appropriate review is 
conducted as part of the reporting process. It is very important not to exclude a group or entity that is impacted by 
the issue, because significant re-work can result if a review oversight is caught late in the process. More importantly, 
though, if a review oversight goes unnoticed, more severe, unidentified consequences could result. Again, the value 
of the ICARE method is the personal accountability and responsibility of the systems engineer to ensure that the 
issue is completely and openly assessed by all effected entities. It is human nature to resist open and full disclosure 
for fear of being critiqued and criticized. The systems engineer must remember that the intent of ICARE is to fully 
and adequately solve the problem. Therefore, the systems engineer must care more about achieving that goal than 
worrying about being criticized for their approach. 

VI. Execute 

The fifth step in resolving an issue is to execute the forward plan for the decisions made. The concept of this step 
is not very complicated, but accomplishing this step may be very involved and labor intensive. Follow the direction 
from the decision authority and complete the issue resolution. Completing the Execute step is very important; 
otherwise, all the effort put into the previous steps will be lost. Depending on the forward plan, several of the 
ICARE steps may be reiterated before final resolution of the issue, and many products, processes and people may be 
impacted by implementing the solution. Documentation of the decisions and direction may be done formally or 
informally, but there should be processes or tools in place to capture the issue resolution. 

The systems engineer must act on the direction provided and the decisions made. If the identified issue was 
assessed to be the result of an inadequate requirement, the Assess step would articulate the change that must be 
made to the associated requirement. During the Report step, the recommendation would be made to the decision 
authority to change that requirement accordingly. With approval, the Execute step would implement the change to 
the requirement and the systems engineer would ensure that the requirement document wording is changed. Further, 
the systems engineer must ensure that the revised requirement gets implemented correctly by the user. This is just 
one simple example, but there could be numerous products or processes that must be changed to implement the 
approved direction. 

In general terms, the NASA Systems Engineering Handbook describes technical control processes that include: 
requirements management, interface management, technical risk management, configuration management, and 
technical data management. These are the systems engineering processes that the systems engineer would use to 
formally implement the Execute step. 

The SSP has established revision controlled databases, documents, data books, drawings, math models, reports, 
criteria, rules, etc. that record revisions since the baseline versions. Configuration Management (CM) of these 
products is essential for maintaining the current state of the system, retaining insight into the system’s evolution and 
capturing the knowledge gained over the years. The Execute step will typically involve making another revision to 
some of these products, and thus involve the CM process. 

A particular database used by the SSP is Problem Reporting and Corrective Action (PRACA). The requirement 
document for SSP PRACA (NSTS 08126), states that “the goal of the SSP PRACA system is to establish a process 
to continuously improve the safety and reliability of Space Shuttle hardware, software, and Ground Support 
Equipment (GSE). The SSP PRACA system will provide the SSP and all SSP design elements/projects: accurate 
and immediate visibility into problems; and an accurate historical database to support trend analysis, provide failure 
history, support investigations, and to document corrective actions. PRACA is only as accurate as the reported 
information. Therefore, sufficient attention must be paid to ensuring accuracy of the reportable problem, failure 
summary, root cause analysis, tracking, and the incorporation of appropriate corrective action to prevent failure 
reoccurrence. 1 ” 

Another important tool for systems engineering is lessons learned, which is knowledge or understanding that is 
gained though experience. “Systems engineers are the main users and contributors to lessons learned systems. 
Systems engineers compile lessons learned to serve as historical documents, requirements’ rationales, and other 
supporting data analysis. Systems engineers’ responsibilities include knowing how to utilize, manage, create, and 
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store lessons learned and knowledge management best practices. 2 ” Some best practices are discussed in the 
handbook, and for additional information, the detailed process for recording lessons learned is explained in NPR 
7120 . 6. 13 

The systems engineer must complete the Execute step to gleam all the value from the ICARE method. The 
benefits of the previous steps will be lost if the issue resolution is not realized and documented for future reference. 
This step is often short-circuited and terminated prematurely to move on to the next issue. The responsibility of the 
systems engineer is to capture all the knowledge gained and make it accessible for future applications. The systems 
engineer must say, “ICARE to finish the problem resolution, make sure the corrective action is implemented 
correctly, and record the lessons learned.” 

VII. Example Applications of the ICARE Method 

A. Space Shuttle Launch Console Operator 

Identify a measurement that has exceeded criteria or is trending adversely, communicate the issue and the 
criticality on the communication loop so the appropriate entities are aware, assess the impacts of the issue and if pre- 
planned contingencies exist, report the assessment results and the recommended forward plan, execute the approved 
plan. 

B. Athletic Talent Scout 

Identify a player with desirable skills, communicate the discovered talent to the team manager and communicate 
interest to the player, assess the player’s full capability and value to the team, report the assessment results to the 
team manager and make a recommendation, execute the decision. 

C. Entrepreneur 

Identify a need, communicate a potential solution (e.g. product or service) to possible customers and 
corroborators or investors, assess the market demand and product feasibility, report a business plan to investors or 
report the new product availability to the consumers via advertising, execute the business plan. 

D. Parent and Doctor 

If a child gets sick, the parent (and/or child) identifies the issue with the child’s health; the parent communicates 
with the child and their spouse about the sickness; the parent assesses the need to bring the child to the doctor. When 
the parent and child arrive at the clinic, they identify and communicate the symptoms to the doctor; the doctor 
assesses the symptoms and, if necessary, runs other tests for additional assessment ; the doctor reports the diagnosis 
and recommended treatment to the parent; the parent decides how to proceed, and they execute the agreed to 
approach for treatment. Throughout the child’s life, the ICARE method can be applied in this manner. This example 
depicts both the iterative and recursive nature of the ICARE method, as well as the multiples users completing the 
ICARE steps from their perspective and expertise to accomplish the best result. 

VIII. Conclusion 

The ICARE Method has been described in detail with emphasis on its relation to systems engineering in the SSP. 
Effective use of the ICARE method increases the safety of the vehicle and crew. Each individual in the program 
must have the accountability and responsibility instilled by the ICARE method to exercise technical rigor and 
critical thinking skills in their job. Most importantly the systems engineer must use the ICARE method while 
examining the integrated vehicle. The nature of integrated systems that involve complex interactions between 
multiple subsystems demands the heightened awareness and personal conviction from the systems engineer. 

Laminated cards have been produced as a quick reference for the ICARE method. PSE&I personnel carry these 
cards on their badge clips as a useful tool to re-enforce the ICARE steps. Images of the ICARE cards are in the 
appendix. 

A few non-engineering examples have been provided to demonstrate the flexibility and adaptability of this 
method. In reality, the ICARE method can be considered a way of thinking, and the importance of applying the 
method increases with the complexity of the system (or object) being examined. 
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Appendix 


The following are images of the ICARE Method laminated card made for PSE&I staff. 


The ICARE Method 

A flexible, widely applicable method for system 
engineers to solve problems and resolve issues 
in a complete manner. This method can be 
tailored by diverse users for direct application 
to Iheir function and will instill the attitude of 
accountability, safety, technical rigor and 
engagement in the issue. 

/- dentify 

Identify potentially integrated issues that may have 
/ impacts to mult pie elements, technical d scipines 
and/or organizations 

C - ommunicate 

Inform the Element in which the issce arose, so the 
Element is aware of potential concerns from the 
C integration perspective. Communicate potentially 
integrated issues to the integration team so all 
systems are aware. 

A - ssess 

Confirm whether or rot the issue is integrated. 
m Assess integrated issues for impacts to all SC&I 
/ 1 products and processes. Identify potential impacts 
to Element products and processes and 
communicate those to the Element for assessment 

R - eport 

Report Uie impacts to management and llie 
n integration community. Have recommendations for 
*» management on how to proceed with resolving the 
integrated issue. 

E - xecute 

Execute forward plan for decisions made Ensure 
the required updates are made to the integration 
C products and processes. Ensure Uie integrated 
*" issue is brought to resolution. Ensure the 
resolution of any associated Element issue 
adequately addresses the inteqration concerns. 


Front of the PSE&I ICARE card Back of the PSE&I ICARE card 
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